The present invention relates to computer software applications, and in particular to a method and component for serialization of images.
The Java(trademark) Development Toolkit version 1.1.x (JDK) does not support the serialization of images. That is, the standard built-in mechanism for capturing and storing the state of an object has not been applied/to the java.awt.Image class.
JDK on the other hand allows primitive data types to be serialized. This means that an application developer can design an application so that any primitive data type objects, including objects comprising primitive data type components, can be written to a file or another area of memory, before an application closes. When the application re-opens, the primitive data types can be de-serialized and so recovered and the application can continue as if it had never closed with the exception that image objects will not have been recovered.
A conventional solution to this problem is for a developer to create a reference to any image file used in an application. The reference being a string can be serialized and thus the image can be made persistent by re-loading the file at the reference when an application re-opens. This method, however, is inconvenient for any Java class that has one or more images as class data members and wishes to support serialization itself as it requires extra programming and also relies on the same image remaining at the same location every time the application opens.
Accordingly, the present invention provides a component for a development kit comprising means for converting an image object into a primitive data type object and means for serializing that object so that the object can be made persistent.
Since all primitive Java types support serialization, the invention allows images to be indirectly serialized by converting them to a primitive data type, and serializing that data type. On reconstruction of a class instance via de-serialization, the primitive data type is reconstructed, and then converted back to an image.
There are standard mechanisms within the JDK to convert an image to an array of integers, and to create an image from an array of integers. A problem with simple conversion from image to integer array and back again is the Volume of data involved. With Java, images are typically loaded from GIF (graphics interchange format) or JPEG data streams, which are converted into a standard format in memory by the Java image classes. This format requires 32 bits of information for each pixel in the image: 8 bits for each of the red, green and blue color planes, and a further 8 bits for the alpha plane that controls transparency. The in-memory representation of an image is therefore considerably larger than the originating GIF or JPEG data stream. Serialization of this representation without compression results in very large serialized data sets.
The GIF format is a lossless compression format that supports up to 256 unique colors. The JPEG format can provide more aggressive compression, and supports more than 256 unique colors, but is a lossy format. An image stored as a JPEG data stream and then reconstituted will not be identical to the original. For the purposes of serialization, a process that may well be repetitive, a lossless compression mechanism is required. The GIF compression is well known, however an alternative industry standard lossless compression mechanism exists in the public domain. Commonly know as Zip, several implementations exist in products. More importantly, an implementation is available as part of the JDK.
Thus, in a further aspect, the present invention provides a component further comprising means adapted to compress the primitive data type object before serialization.
By compressing the array of integers obtained from an image using the built-in Zip facility of the JDK, some useful compression can be obtained. In some cases the degree of compression is better than the original GIF data stream, especially with small images. However, in many cases the degree of compression is not as good. This is not surprising, since the Zip algorithms are general purpose, and have no specialized knowledge of the image data that they are compressing.
Thus, in a further aspect the present invention provides a component further comprising: means adapted to convert said image object to an array of integers representing the image pixels; means adapted to create a color table of unique integers from the integer array; means adapted to convert each integer in the integer array into an index into the color table: wherein said compression means is adapted to compress the combined color table and array of indices.
This aspect of the invention provides a component for compressing images, without data loss, that is more effective than the industry standard GIF format.
In this aspect, a color table of the unique colors that exist in the image is created, and image pixels are represented as indices into the color table. Depending on the number of unique colors, the number of bits required to hold each index may be much less than the 32 bits required to represent the pixel color itself. In the case of images originating from a GIF data stream, where a maximum of 256 colors are supported, each index need only ever be 8 bits. For images of greater color depth, various schemes may be employed to limit the number of bits required for each index.